AWS SSOでコマンドラインツールのための一時的な認証情報を取得する
はじめに
中山(順)です
AWS CLIを利用する場合、認証情報をどのように管理していますか?
アクセスキーを発行して設定ファイルに保存しておくこともできますが、よりセキュアな運用を実現したいのであれば一時的な認証情報を利用するべきでしょう。
EC2インスタンスの場合には、IAMロールを設定しておけばインスタンスメタデータ経由で自動的に取得してくれます。
Amazon EC2 インスタンスで実行するアプリケーションに対し、ロールを使用する
Cloud9であれば、EC2同様にIAMロールを利用することもできますし、コンソールにログインしているユーザーの権限を有した一時的な認証情報を利用することもできます。
AWS Managed Temporary Credentials
それでは、ローカルPCにおいて一時的な認証情報を利用する場合にはどのようにするといいでしょうか?
AWS SSOを利用することで、簡単に一時的な認証情報を取得することが可能です。 実はこの機能、半年前にリリースされた機能です。
気づいていた方はすでに利用されているかと思いますが、知らないって方はめっちゃ便利なので是非ご確認ください。
やってみた
というわけでやってみました。
前提作業
とはいいましても、AWS SSOの有効化/ディレクトリの紐付け/AWSアカウントに対するドメインユーザーの関連付けができていればすぐに利用可能です。
AWS SSOの基本設定はこちらのブログにまとまっています。
認証情報の取得
AWS SSO専用のログイン画面からログインし、連携しているアカウントを展開します。 すると、"Command line and programmatic access"というリンクがありますのでこれをクリックします。
すると、以下の画面が表示されます。
一時的な認証情報として、以下の情報が表示されます。
- アクセスキー
- アクセスシークレット
- セッショントークン
これらの情報に加え、いくつかの設定方法も表示されます。
環境変数
最初に環境変数を設定する方法が表示されています。 Mac / Linux環境であればexportコマンドで環境変数を設定できますが、AWS SSOではそのコマンド込みで表示してくれるので、コピペするだけでOKです。 ありがたや。
AWS CLI / SDKで利用する環境変数は以下のドキュメントをご確認ください。
認証情報ファイル
認証情報ファイルに書き込んで利用することも可能です。 その場合でもコピペすればいいようにできています。 手順が単純化できて助かりますね。
認証情報ファイルの利用方法は以下のドキュメントをご確認ください。
補足:両方設定したらどっちが優先されるの?
結論としては、環境変数が優先されます。
認証情報を指定する方法は他にもいくつかありますが、それらも含めた優先順位は以下のドキュメントに記載されています。
動作確認
実際に動作を確認してみましょう。
環境変数
まずは環境変数で設定してみます。
export AWS_ACCESS_KEY_ID="xxxxxxxxxxxxxxxxxxxxxxxx" export AWS_SECRET_ACCESS_KEY="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" export AWS_SESSION_TOKEN="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
aws configure listコマンドで確認します。 Typeがenvになっていることが確認できます。
aws configure list
Name Value Type Location ---- ----- ---- -------- profile <not set> None None access_key ****************YQVC env secret_key ****************vDB0 env region ap-northeast-1 config-file ~/.aws/config
aws sts get-caller-identityコマンドでも確認してみましょう。
aws sts get-caller-identity
{ "Account": "xxxxxxxxxxxx", "UserId": "XXXXXXXXXXXXXXXXXXXXX:(Domain user name)@(Domain name)", "Arn": "arn:aws:sts::xxxxxxxxxxxx:assumed-role/AWSReservedSSO_AdministratorAccess_xxxxxxxxxxxxxxxx/(Domain user name)@(Domain name)" }
なお、環境変数はunsetコマンドで削除可能です。
unset AWS_ACCESS_KEY_ID unset AWS_SECRET_ACCESS_KEY unset AWS_SESSION_TOKEN
認証情報ファイル
次は認証情報ファイルで設定してみます。
~/.aws/credentialsに以下のテキストを追記します。 プロファイル名はコマンドを実行する際に利用します。
[XXXXXXXXXXXX_AdministratorAccess] aws_access_key_id = XXXXXXXXXXXXXXXXXXXX aws_secret_access_key = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX aws_session_token = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
aws configure listコマンドで確認します。 その際、プロファイルを指定します。 Typeがshared-credentials-fileになっていることが確認できます。
aws configure list --profile XXXXXXXXXXXX_AdministratorAccess
Name Value Type Location ---- ----- ---- -------- profile XXXXXXXXXXXX_AdministratorAccess manual --profile access_key ****************EOFR shared-credentials-file secret_key ****************ZQFh shared-credentials-file region <not set> None None
aws sts get-caller-identityコマンドでも確認してみましょう。 この部分は環境変数の場合と差はありません。
aws sts get-caller-identity --profile XXXXXXXXXXXX_AdministratorAccess
{ "Account": "xxxxxxxxxxxx", "UserId": "XXXXXXXXXXXXXXXXXXXXX:(Domain user name)@(Domain name)", "Arn": "arn:aws:sts::xxxxxxxxxxxx:assumed-role/AWSReservedSSO_AdministratorAccess_xxxxxxxxxxxxxxxx/(Domain user name)@(Domain name)" }
留意点
認証情報の有効期間
この機能で取得した一時的な認証情報は、60分で失効します。 失効した場合には再取得してください。
まとめ
このように、AWS SSOを利用することでマルチアカウント環境でも一時的な認証情報を簡単に取得できます。
構築や運用においてAWS ACL / SDKを利用している場合、 一時的な認証情報を利用することで永続的な認証情報を利用する場合と比較してセキュリティリスクを下げることができます。
マルチアカウント環境では認証情報の管理が雑になりがちなので、ルールやガイドラインを作っても人間がそれを守ってくれるとは限りません。だってにんげんだもの。 少しでも人間に頼らず、システムに頼っていきましょう。
同様の機能はサードパーティのサービスでも利用できるものがあるかと思いますが、AWS SSOは無料で利用できますので要件がマッチするのであればまずは気軽に使い始めてみることをおすすめします。 使っていた上で足りない機能があれば、他のサービスの利用を検討するとよいかと思います。
現場からは以上です。